Description

Introduce a new MCP server (oci-support-mcp-server): OCI Support Service (CIMS). This server exposes tools to create and query OCI Support tickets related to technical issues, account/billing issues and limit increase requests.

Key changes

• New package at src/oci-support-mcp-server with:

  • pyproject.toml and package scaffolding
  • Server implementation (oracle/oci_support_mcp_server/server.py)
  • Data models (oracle/oci_support_mcp_server/models.py)
  • init files and README/License

• New unit tests:

  • oracle/oci_support_mcp_server/tests/test_support_tools.py

Implemented tools (OCI Support (CIMS) APIs)

• list_incidents
• get_incident
• create_incident
• list_incident_resource_types
• validate_user

Motivation:

• Provide an MCP-compliant interface for OCI Support Service operations, enabling tools-based automation and summarization within MCP-enabled editors/agents.
• Add test coverage to ensure correctness of request shaping, response handling, and summary logic.

Dependencies:

• Uses OCI Python SDK (already standard in this repository’s ecosystem).
• No new external runtime dependencies beyond those specified in the new subpackage’s pyproject.toml.

Type of change

Please delete options that are not relevant.

• New feature (non-breaking change which adds functionality)

How Has This Been Tested?

• Added unit tests for server and models:
  • oracle/oci_support_mcp_server/tests/test_support_tools.py
  • oracle/oci_support_mcp_server/tests/test_models.py

Reproduce locally:

• python -m venv .venv && source .venv/bin/activate
• cd src/oci-support-mcp-server
• uv pip install -e .
• uv run pytest -q

Notes:

• Test A: Server and model unit tests (mocked)

Test Configuration:

• Firmware version: N/A
• Hardware: N/A
• Toolchain: Python 3.x, pytest
• SDK: OCI Python SDK (mocked in tests)

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules